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(54) Distribution of data in a peer-to-peer network 



(57) The present invention relates to the field of net- 
works and, more particularly, to peer to peer networks. 
Accordingly, the present invention allows data to be dis- 



tributed amongst devices in a network, without requiring 
a central server or controller to control and manage the 
distribution. 
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Description 

Field of tiie Invention 

[0001] The present Invention relates to the field of net- 
works and, more particularly, to peer to peer networks. 

Background of the Invention 

[0002] Networks of devices are well known in the field 
of information technology. Typically, such networks al- 
low different devices in the network to communicate with 
one another and are generally controlled by a central 
server that is responsible for managing the communica- 
tion between the different devices in the network. 
[0003] Figure 1 is a block diagram of such a centra! 
server based system according to the prior art. A 
number of devices 101a to 101 n are connected via a 
network 104 to a central server 102. If the device 101a 
wishes to distribute data to other devices In the network, 
e.g. devices 101b to 101 n, the device 101a sends the 
data to the central server 102. The central server 102 
knows which devices are connected to it, and therefore 
is able to distribute the data as appropriate to the devic- 
es 101b to lOln. If devices are added or removed from 
the network the central server 102 must be updated ac- 
cordingly. In a system of this type, a central server is 
required to oversee the central administration of the net- 
work. 

[0004] One network configuration that does not rely 
on a central server is the so-called Freenet, details of 
which can be found at http://freenet.sourceforge.net/ 
[0005] Figure 2 Is a block diagram showing an exam- 
ple of a network according to the Freenet network. A 
number of devices 200a to 200e are shown. The device 
200a stores a file 202 in a database or other storage 
means associated with the device. The file 202 is signed 
with a signing function, for example, a hashing function, 
to generate a unique signature for the file. In Figure 2 
the unique signature is shown as being AAA. 
[0006] If a user of the device 200e wishes to retrieve 
the file 202 from the network it must first of all know the 
signature of the file to be retrieved. If the requested file 
does not reside already in the device 200e the device 
200e sends a request for the file to other devices to 
which it is connected; in this case the device 200d. The 
device 200d checks to see whether it has a file with the 
matching signature stored in the device. If the device 
200d does have the requested file 202, It supplies the 
requested file to the device 200e. If the device 200d 
does not have the requested file, it too requests the file 
from other devices to which it is connected. 
[0007] Eventually, the device 200b requests the file 
202 from the device 200a. which supplies the file to the 
device 200b. The device 200b stores the file and trans- 
mits it back to the device that made the direct request, 
I.e. the device 200c. This process continues until re- 
quested file Is delivered to the device 200e that made 



the initial request. Typically, if a file stored on the network 
is not accessed over a long period of time, the file gets 
overwritten and therefore removed from the network. 
Where a particular file is accessed frequently, the file 
5 will migrate around the network and will eventually be 
stored on devices close to where the requests for that 
file are made from. 

[0008] One of the major problems with the Freenet 
configuration is that retrieve times can be slow, since file 

10 requests are dealt with on an as and when basis. In other 
words, if a device requests a file that is not stored locally, 
a search spreads out across the whole network trying 
to locate the file. This is not only laborious, but can also 
use large amounts of network bandwidth. Additionally, 

15 in order to retrieve a file the signature of the file must be 
known. 

Summary of the Invention 

20 [0009] One aim of the present invention is to provide 
an improved network and devices for use thereon which 
overcome the above-mentioned problems of the prior 
art. 

[0010] Accordingly, the present Invention allows data 
25 to be distributed amongst devices In a network, without 
requiring a central server or controller to control and 
manage the distribution. This is particularly advanta- 
geous in large networks with many hundreds or thou- 
sands of devices, where having a central server is gen- 
30 erally neither feasible nor desired. 

[0011] According to a first aspect of the present inven- 
tion, there is provided a method of distributing data in a 
network of devices, wherein each device comprises a 
database and is capable of communicating with at least 
35 one other device in the network, the method comprising: 
maintaining in the database a list of devices in the net- 
work; selecting a device from the list devices; selecting 
a portion of the database; distributing the selected por- 
tion of the database to the selected device; receiving 
"fo data from at least one other device in the network; and 
updating the database In accordance with the received 
data. 

[0012] According to a second aspect of the present 
invention, there is provided a device for distributing data 

45 in a network of devices, wherein each device comprises 
a database and is capable of communicating with at 
least one other device in the network comprising: means 
for determining a list of devices in the network; means 
for selecting a device from the list; means for selecting 

50 a portion of the database; means for distributing the se- 
lected portion of the database to the selected device; 
means for receiving data from at least one other device 
in the network; and means for updating the database in 
accordance with the received data. 

55 

Brief Description of the Invention 

[0013] An example embodying the invention will now 
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be described, by way of non-limiting example, with ref- 
erence to the accompanying drawings, in which: 

Figure 1 is a block diagram of such a central server 
based system according to the prior art. ; 
Figure 2 is a block diagram showing an example of 
a network according to the Freenet network; and 
Figure 3 shows a block diagram of a system ac- 
cording to an embodiment the present invention. 

Best IVIode of Carrying out the Invention 

[0014] Figure 3 shows a block diagram of a system 
according to an embodiment of the present invention. A 
network 310 of devices 300a to 300n is illustrated. Each 
of the devices 300a to 300n includes a transceiver (302a 
to 302n respectively) enabling them to communicate 
with other devices In the network and a database (304a 
to 304n respectively). A transceiver is herein defined as 
a means for receiving and transmitting signals and data 
for the purposes of communication. A transceiver may 
be, for example, a network adapter, a modem or other 
suitable means. A transceiver may be either a combined 
receiver/transmitter, or may comprise separate recep- 
tion and transmission means. 

[0015] The network may be an Internet protocol (IP) 
or other appropriate network. Each of the devices 300a 
to 300n may be any kind of appropriate device, for ex- 
ample, personal computers, servers, mobile devices in- 
cluding portable radiotelephones and so-called person- 
al digital assistants (PDA), laptop computers etc. For the 
sake of simplicity of explanation, however, the descrip- 
tion herein will initially only consider a network of per- 
sonal computers. Those skilled in the art will appreciate 
that the other types of appropriate devices mentioned 
above may be substituted in place of a personal com- 
puter without detracting from the inventive concepts de- 
scribed herein. 

[001 6] In a first embodiment each of the devices 300a 
to 300n maintain, in their respective databases, details 

of other devices in the network. The contents of each 
database are arranged into what are herein referred to 
as database objects. 

[0017] The way in which the contents of each data- 
base are acquired and maintained is described below. 
[0018] The database 304a of device 300a contains a 
list of database objects each of which contain details of 
a different device In the network 310 with which it may 
communicate. The device 300a selects at least one da- 
tabase object relating to at least one of the other devices 
In the network 310 and transmits a portion of its data- 
base 304a to the selected device or devices. The trans- 
mitted portion of the database contains at least the ad- 
dress or network name of the device 300a. It should be 
noted that the transmissions are unsolicited, i.e. they are 
not requested by the receiving device. 
[001 9] The device 300a may select a database object 
In the database 304a using a variety of different meth- 



ods, such as random selection, pseudo-random selec- 
tion, sequential or other algorithm-based selection. 
[0020] Preferably a time stamp Is Included with each 
database object to indicate the time at which the data- 
5 base object was sent. Additionally, a unique identifier is 
preferably included with the transmitted database ob- 
ject. The unique identifier may be generated by any 
number of known methods, for example using a combi- 
nation of the media access controller (MAC) address, 
the number of seconds since 1 January 1 970, and a ran- 
domly generate number. 

[0021] In the example shown in Figure 3, device 300a 
chooses to transmit a portion of its database 304a to the 
device 300c. The portion of the database chosen for 
transmission may, for example, be the whole contents 
of the database, i.e. all the database objects in the da- 
tabase. Alternatively the chosen portion may contain on- 
ly to some of the database objects, and hence relate to 
only a specific device or devices. 
[0022] On receiving a database object, the device 
300c checks its database 304c to determine whether the 
database object exists already. This may be achieved 
by checking the unique Identifier of the received data- 
base object. If the database 304c of device 300c does 
not contain the received database object, the received 
database object is stored therein. If the database 304c 
does contain the received database object the times- 
tamp of the database object Is checked against the 
timestamp of the database object stored In the database 
304c. From the timestamps it is determined whether the 
received database object is more recent than that al- 
ready stored. The received database object is stored in 
the database only where the received database object 
is more recent than that already stored. In a preferred 
embodiment, where a database object received by a de- 
vice is older than that stored on Its own database, the 
receiving device transmits its copy of the database ob- 
ject back to the sending device, thereby enabling Its da- 
tabase to be updated. 

[0023] Each device in the network performs the same 

tasks described above. Over time, each device builds 
up and maintains a database of database objects, and 
therefore contains details of other devices in the net- 
work. 

[0024] Each device may be preprogrammed to deter- 
mine both the frequency at which it sends database ob- 
jects to other devices in the network and the number of 
devices to which database objects are sent. If the fre- 
quency of sending database objects Is low, the time tak- 
en for every device in the network to know about other 
devices in the network will be long, resulting In Inaccu- 
rate or out-of-date data in the databases of some devic- 
es. At the same time, however, the associated network 
traffic will be minimal. 

[0025] If the frequency of sending database objects is 
high, the data In the databases of the devices in the net- 
work will be more accurate, and will adjust more quickly 
to changes In individual devices. Consequently, the as- 
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sociated network traffic will be high. 
[0026] It can be estimated that the convergence of the 
network is of the order of P.log(N), where P = transmis- 
sion interval and N = number of peers. For example, in 
a network with 1 000 devices each having a transmission 
interval of 5 seconds, the overall convergence is of the 
order of 5xlog(1000) = 50. This means that half conver- 
gence is reached after only 50 seconds. 
[0027] If a device is removed from the network it will 
no longer be available should another device attempt to 
transmit a database object to it. In this case, the data- 
base object relating to the unavailable device may either 
be removed from the database, or, preferably, may be 
updated to show that the device is unavailable. 
[0028] When a new device is connected to the net- 
work, the new device can acquire details of other devic- 
es in the network in a number of ways. For example, the 
new device may send a broadcast message requesting 
that other devices send their address details. One alter- 
native is to enter into the database of the new device 
the address of a known device in the network. Once the 
new device has at least one address in its database, the 
new device will quickly acquire details of other devices 
in the network. 

[0029] The frequency of transmitting database ob- 
jects is preferably adapted according to device type. For 
example, a PDA or mobile device may only be connect- 
ed to the network for short periods of time. It may there- 
fore preferable that the information in the network is up- 
dated frequently. On the other hand, a server, which is 
permanently connected to the network, may need to 
transmit database objects from its database less often. 
[0030] In a preferred embodiment the frequency at 
which database objects are transmitted from one device 
to another varies according to device type. For example, 
for devices which do not change their status often, such 
as business PC's, a low frequency, e.g. 1-10 minutes, 
is sufficient. For mobile devices, on the other hand, a 
higher frequency, e.g. approximately every 1-10 sec- 
onds, may be desirable. This helps to ensure fast con- 
vergence of the information in the network. The frequen- 
cy need not be constant for a particular device and may 
vary over time. For example, it may be preferable to In- 
crease the frequency of transmission when a device is 
initially connected to the network, or if data on the device 
is changing rapidly. 

[0031] Each device on the network is responsible for 
the management of its own database and may imple- 
ment any number of ways for managing its database 
contents. For example, if required database objects may 
be overwritten according to a least recently used (LRU), 
least frequently used (LFU) or other appropriate algo- 
rithm. 

[0032] The above-described example embodiment il- 
lustrates how a network according to this embodiment 
adapts and converges so that, within a short time, most 
or all of the devices in the network have details of most 
or all of the other devices in the network. 



[0033] In a further embodiment, the database objects 
transmitted between devices may, in addition to includ- 
ing device address information, additionally include in- 
formation relating to the device type and the availability 

5 of resources of the device. The information relating to 
the device type may indicate, for example, whether a 
device is a personal computer, a server, a PDA, a mobile 
device etc. The information relating to the availability of 
resources may indicate, for example, the processor type 

10 of a device, the amount of memory or disk storage avail- 
able, whether a device is currently connected to the net- 
work etc. 

[0034] It is preferred that each database stores data- 
base objects relating to both 'relevant' and 'non-relevant' 
15 devices in the network. Relevant devices may be de- 
fined according to the following criteria: proximity of the 
device in the network e.g. network latency required to 
reach the device; computing capability of the device; 
probabilistic availability. Other criteria may also be used. 
20 A relevant device may, for example, be a device which 
is on the same network subnet, has available computing 
capability (e.g. not a PDA or mobile telephone) and is 
often in an idle state. It is preferable for each device to 
store information about local devices, which are gener- 
25 ally more useful to the device, than to store details about 
distant devices. The purpose of storing details of some 
non-relevant devices is to improve the convergence of 
data in the network. Each device may apply the criteria 
differently or even have different criteria for determining 
30 'relevant' and 'non-relevant' devices. 

[0035] In a preferred embodiment, around 0 to 10% 
of the database of a device Is used to store database 
objects of non-relevant devices. In a private or closed 
network there may be no devices designated as non- 
35 relevant. 

[0036] This embodiment is particularly useful in the 
field of distributed computing and cluster networks as 
well as in other fields which allow the resources of other 
network devices to be known and used remotely. For 
40 example, if the device 300a wishes to carry out a com- 
puting task, such as the rendering of a large graphics 
file the device 300a may use the information in its data- 
base to determine which devices in the network may be 
used to perform this task. 
45 [0037] In yet a further embodiment additional data- 
base objects are stored in each device database. These 
additional database objects are transmitted between 
devices in the mannerdescribed above. These addition- 
al database objects may be, for example, file or other 
50 data packages. For example, the device 300a may de- 
cide to publish a database object (contained in the da- 
tabase 304a) to the network. In this context publish 
means the initial making available to the network of a 
database object. 
55 [0038] Referring again to Figure 3, the device 300a 
decides to publish a database object to the network. 
One way in which this may be achieved is to store the 
required database object in the database 304a. By do- 
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ing so the database object is capable of being selected 
and transmitted to other devices in the network using 
the above-described mechanism. The selection and 
transmission of database objects is preferably carried 
out in accordance with the above-description and in ad- 
dition to the selection and transmission of database ob- 
jects relating to network devices described above. 
[0039] In this way. a database object made available 
in a device database will, after convergence, be stored 
in most of the other device databases in the network 
310. Thereafter, should another device in the network 
require the same database object it should be located 
locally in its database. This enables a device to be able 
to access a database object locally, without requiring 
further network access. 

[0040] One particularly useful feature is the ease with 
which a database object can be updated across the 
whole network. For example, if the device 300a modifies 
a database object, the modified database object wilt 
quickly be updated on other devices in the network, us- 
ing the distribution mechanisms described above, with- 
out requiring any specific action from a device or user. 
[0041] In a still further embodiment, a mechanism to 
effectively force the update of a device database may 
be employed. This is particularly useful in the case of 
mobile devices, or other devices which are not constant- 
ly connected to the network. A mobile device may only 
be connected to the network for short periods of time, 
for example, whilst downloading email or phonebook In- 
formation. It is possible that the mobile device may be 
disconnected from the network before it has a chance 
to receive updated database objects from other devices 
on the network. One way in which such a device can 
force an update of its database Is to choose a device 
upon connection to the network and to send the contents 
of its database to the known device. As described 
above, if the chosen device receives a database object 
which is the same but older than the one in its database, 
it will respond by sending back its copy of the database 
object. This will in turn cause an update, where required, 
of the database objects in the database of the mobile 
device. Preferably the device chosen upon connection 
to the network is a device which is known to be constant- 
ly connected to the network. 

[0042] It will be appreciated that the device databases 

throughout the network may not necessarily be com- 
pletely synchronized with the other device databases in 
the network. For example, a device could be disconnect- 
ed from the network for a period of time thereby prevent- 
ing its database from being updated with any new data- 
base objects. Also, a device database may have limited 
storage capacity, for example on a PDA or mobile de- 
vice, and therefore be physically unable to store all da- 
tabase objects received. In the above-described em- 
bodiment relating to distributed computing, for example, 
the accuracy of each database is not necessarily critical. 
Consider the situation where a database of a first device 
inaccurately reports that a second device is unavailable 



when it is in fact available. In this case, the first device 
will not be able choose the second the device for a dis- 
tributed processing task, and will therefore be forced to 
choose another available device. On the other hand, if 
5 the database of the first device reports that a second 
device is available when in fact it is not, the first device 
will realize that the second device is not available as 
soon as it attempts to communicate the second device. 
This will therefore lead to the device database being up- 
10 dated to reflect the correct status of the device, which 
will in turn lead to the updating of other device databases 
in the network. 

[0043] The present invention therefore provides a 
self-sustaining network of devices in which each device 
15 (or element) of the network essentially functions inde- 
pendently of each other. This leads to a robust network 
with no central server and therefore requires no central 
maintenance or administration. 



1 . A method of distributing data in a network of devic- 
es, wherein each device comprises a database and 

25 Is capable of communicating with at least one other 
device in the network, the method comprising: 

maintaining in the database a list of devices in 
the network; 

30 selecting a device from the list devices; 

selecting a portion of the database; 
distributing the selected portion of the database 
to the selected device; 

receiving data from at least one other device in 
35 the network; and 

updating the database in accordance with the 
received data. 

2. The method of claim 1 , wherein the step of receiving 
40 data is adapted for receiving unsolicited data. 

3. The method of claim 1 or 2, further comprising clas- 
sifying devices listed in the database into relevant 
and non-relevant devices. 

45 

4. The method of claim 3, wherein the step of main- 
taining is adapted to maintain a list of both relevant 
and non-relevant devices in the network. 

50 5. The method of any previous claim, wherein the step 
of selecting a device is adapted to select a device 
using pseudo-random selection. 

6. The method of any previous claim, wherein the step 
55 of selecting a portion of the database Is adapted to 

select the whole contents of the database. 

7. The method of any previous claim, wherein the 
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steps of selecting a device, selecting a portion and 
distributing frequency are performed repeatedly 
with a non-constant frequency. 

8. The method of any previous claim, wherein the step 
of selecting a device is adapted to selecting a plu- 
rality of devices, and further wherein the step of dis- 
tributing Is adapted to distributing to the plurality of 
selected devices. 

9. A device for distributing data in a network of devic- 
es, wherein each device comprises a database and 
is capable of communicating with at least one other 
device in the network comprising: 



10 



15 



means for determining a list of devices in the 
network; 

means for selecting a device from the list; 
means for selecting a portion of the database; 
means for distributing the selected portion of 20 
the database to the selected device; 
means for receiving data from at least one other 
device in the network; and 
means for updating the database in accord- 
ance with the received data. 25 

10. The device of claim 9 operating according to the 
method of claims 1 to 8. 

11. A network of devices comprising a plurality of de- 30 
vices as claimed In claims 9 or 10. 
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